go_bunzee

Lessons from PM with Dev Team | 매거진에 참여하세요

questTypeString.01quest1SubTypeString.02
publish_date : 25.08.01

Lessons from PM with Dev Team

#jira #teamwork #asana #trello #team #membership #talk #common #listen

content_guide

10 Hard-Earned Lessons from Managing Developers as a PM

Working with developers isn’t just about shipping features or moving tasks across a board.

It’s about trust, structure, empathy — and knowing when to get out of the way.

As a project manager, you’re the bridge between technical execution and business outcomes.

And if you're working with developers, you know: this job is part choreography, part diplomacy.

Here’s what I’ve learned (often the hard way) about collaborating with dev teams — and making the work not only efficient but human.

1. Make Developers Feel Like Team Members, Not Service Providers

The most powerful thing you can do? Build a space where developers feel psychologically safe — like actual stakeholders, not outsourced executors.

That means:

  • Involving them in ideation, not just execution

  • Listening deeply (not just waiting to speak)

  • Recognizing their expertise without micromanaging

You can’t fake respect. Developers know when they’re being treated as code monkeys. And they check out fast when that happens.

2. Don’t Be the Bottleneck — Be the Buffer

Your job is to protect the team from chaos — not to add to it.

  • Keep stakeholders from scope-creeping directly into devs’ DMs

  • Maintain clear boundaries between business needs and team execution

  • Prioritize clarity over control

Yes, you’ll feel pressure from above. But that’s not your team’s burden. It’s yours to absorb — and translate into productive, actionable plans.

3. Use Rituals, Not Micromanagement

Daily standups, sprint planning, retros — they work for a reason. Structure creates freedom. Clear expectations reduce stress.

Here’s what I stick to:

  • 10-minute daily standups

  • No check-ins outside that unless something’s blocking progress

  • Weekly reviews with async notes on Slack or Notion

  • Monthly retros to improve the how, not just the what

Micro-checking in? It’s not helpful. Focus on outcomes, not keystrokes.

4. Treat Problems Like Pilots Do

If something goes wrong, don’t panic. Don’t blame.

Take a breath. Then ask:

  • What happened?

  • When did we know?

  • What can we learn?

Panic spirals are contagious. Calm is, too.

5. Use a Single Source of Truth

Slack is great — until it isn’t. Developers can’t chase updates across five different tools.

Stick to one centralized hub for:

  • Documentation (Confluence, Notion, etc.)

  • Task tracking (JIRA, Asana, Trello)

  • Status communication

My rule of thumb? If it’s not written down, it doesn’t exist.

6. Handle Stakeholders Like a Pro

Some stakeholders will try to skip the line and message your devs directly.

Here’s how I handle it:

  • Gently redirect them to me

  • Invite them into structured feedback loops (like testing new versions)

  • Give them visibility, but not control

They want to feel included. That’s fair. Just make sure it happens on your terms — not in a way that derails your team.

7. Document Everything (Especially Remotely)

In-office, you can solve things next to the coffee machine. Remote? Not so much.

Documentation becomes your best ally.

  • Record meeting notes

  • Track decision history

  • Clarify “what done looks like”

Documentation isn’t busywork — it’s clarity at scale.

8. Don’t Just Manage Work — Manage Energy

Burnout isn’t about long hours. It’s about long hours of ambiguity, pressure, and feeling alone.

Your job is to:

  • Give context

  • Break down big goals into achievable chunks

  • Celebrate progress, not just results

If your team trusts you to have their back, they’ll go further than you expect.

9. Tools Matter, But People Come First

JIRA, Asana, Trello — they’re all fine. I prefer JIRA because of its integration with Confluence and Git. But honestly?

A mediocre tool + clear communication > the best tool + team confusion.

Pick what fits your team’s rhythm. And don’t be afraid to switch if it’s not working.

10. Hire for Emotional Intelligence, Not Just Technical Skill

The best developers I’ve worked with? They aren’t just great at code.

They’re great at communication, collaboration, and thinking in systems.

And the best PMs I’ve met? They aren’t just organizers.

They’re connectors.

Soft skills are the hard skills when building real teams.

Final Thought

Managing developers isn’t about controlling them. It’s about enabling them — and learning alongside them.

The goal isn’t just velocity or clean burndown charts.

It’s building a culture where technical teams thrive, trust each other, and solve real problems together.

You’re not just shipping products. You’re shaping how people work together.

And that’s where the real impact happens.